Given the broad spectrum of usage of microcomputers in controlling subsystems of mission critical systems, it is of utmost importance that the interface between the microcomputers and system elements implementing critical functions remain safe during fault conditions within the microcomputer. Such fault conditions may occur in either hardware or software part of the microcomputers. One such example is an unintended execution of otherwise normal software code due to incorrect state information such as program counter value, corrupt stack pointer or stack contents.
One class of mission critical systems is implantable cardiac rhythm management systems, in which electrical therapy is delivered to the heart. The same therapy sequences that are life sustaining may be life threatening if delivered with inappropriate timing. The decision to deliver electrical therapy generally involves the execution of complex algorithms that must be correctly executed to insure the appropriateness of delivered therapy. In the event of fault conditions that compromise the ability of the system to correctly execute such an algorithm, it is critical that inappropriate therapy be blocked, and that the system operation be restored as quickly as possible.
Generally hardware and software locks are used to protect such system critical functions from inadvertent actuation. It is generally desired that such protection mechanisms be effective and efficient in requiring minimum hardware and software to provide satisfactory protection. Furthermore, it is desirable that the latency to actuation be well controlled and that the interval of time during which a critical task is accessible be short and well defined. Protection mechanisms that are effective in preventing unintended unlocking of actuation due to random processor actions are straightforward. They are generally a unique, necessary, and sufficient sequence of a software code (interacting with hardware), which is sufficiently unlikely to have been replicated either by localized or by non-localized random processor action.
Generally the method employed by mechanisms protecting against inappropriate therapy activation involves providing some degree of complexity in the interface to the hardware that activates the therapy. This can be illustrated, for example, with an interface to a microcomputer, that requires more than one bit be set in the input/output space before activation of the critical therapy can occur. Requiring a specific order or time sequence for setting the bits further restricts possible inadvertent activation, as does placing the bits at different input/output locations. With an interface of sufficient complexity, it is extremely unlikely that random activations of the interface by a malfunctioning subsystem or subsystems will result in therapy delivery.
This protection mechanism can generally be enhanced by placing a time limit on unlocking an actuation of a particular critical task, such that the likelihood of random actuation of that task in combination with the specific code to unlock that task within the requisite time period is even more unlikely. It is important to note that there is a limit to the efficacy of a software code sequence in preventing unintended random unlocking of actuation. To illustrate, assume that the unlocking software sequence is sufficiently improbable that only one occurrence of it exists in a device memory, and that occurrence is an intended key that unlocks the critical task. Further assume that this code fragment is protected from being “run over” by a runaway processor and/or by software reset opcodes that precede it in memory. Under these assumptions, the only single random event that can cause execution of the fragment is if the instruction pointer is somehow pointed exactly at unlocking. This is not altogether an improbable event though the probability of its occurring is generally on the order of 2−16 or greater. Generally, however, such hardware locks are fairly easy to circumvent and by themselves afford little to no protection against unintended execution. Therefore, there is a need for an improved mechanism to protect from an unintended execution of critical tasks.